What is the noun form of "atomic" ?
richardchaven
"quickly"), what is the noun form of "atomic" in the sense of
indivisible ?
"Indivisibility" does not have the right ring to it.
Any ideas ?
Salvatore Volatile
Atomicity.
--
Salvatore Volatile
vorot...@yahoo.com
No, it's atomicitousness.
Seriously, the noun form of atomic is atom.
Skitt
Opinions are split on that one.
--
Skitt
Jes' fine
BST
> Salvatore Volatile wrote:
>> richardchaven wrote:
>>> Just as "performance" or "speed" is the noun form of "fast" (or
>>> "quickly"), what is the noun form of "atomic" in the sense of
>>> indivisible ?
>>>
>>> "Indivisibility" does not have the right ring to it.
>>>
>>> Any ideas ?
>> Atomicity.
>
>
> Seriously, the noun form of atomic is atom.
Be that as it may, the answer to richardchaven's question is "atomicity".
Mark Brader
>>> "quickly"), what is the noun form of "atomic" in the sense of
>>> indivisible ?
>>>
>>> "Indivisibility" does not have the right ring to it.
>>>
>>> Any ideas ?
>>
>> Atomicity.
>
> Opinions are split on that one.
Atomicity.
--
Mark Brader "'A matter of opinion'[?] I have to say you are
Toronto right. There['s] your opinion, which is wrong,
m...@vex.net and mine, which is right." -- Gene Ward Smith
Steve Hayes
wrote:
Individual.
--
Steve Hayes from Tshwane, South Africa
Web: http://hayesfam.bravehost.com/stevesig.htm
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
R H Draney
Nonetheless, it is as near the right word as any you're going to find...note
that the word "atom" comes from the Greek roots "a-" ("not") and "tomos" ("to
cut"), so an atom is simply that which can't be cut into smaller pieces....r
--
"Keep your eye on the Bishop. I want to know when
he makes his move", said the Inspector, obliquely.
Jeffrey Turner
>>>>Just as "performance" or "speed" is the noun form of "fast" (or
>>>>"quickly"), what is the noun form of "atomic" in the sense of
>>>>indivisible ?
>>>>
>>>>"Indivisibility" does not have the right ring to it.
>>>>
>>>>Any ideas ?
>>>
>>>Atomicity.
>>
>>Opinions are split on that one.
>
>
> Atomicity.
Sal's joke bombed.
--Jeff
--
The shepherd always tries to persuade
the sheep that their interests and
his own are the same. --Stendhal
Evan Kirshenbaum
> richardchaven filted:
>>
>>Just as "performance" or "speed" is the noun form of "fast" (or
>>"quickly"), what is the noun form of "atomic" in the sense of
>>indivisible ?
>>
>>"Indivisibility" does not have the right ring to it.
>
> Nonetheless, it is as near the right word as any you're going to
> find...note that the word "atom" comes from the Greek roots "a-"
> ("not") and "tomos" ("to cut"), so an atom is simply that which
> can't be cut into smaller pieces....r
In computer science, the word is "atomicity". When you guarantee the
atomicity of an operation, you guarantee that it all happens or all
fails to happen: it can't fail partway through without undoing any
changes it may have made and nobody can observe it when it's made
some, but not all, changes or change the things it depends on after
it's observed them but before it finishes.
Actually, come to think of it, the word has somewhat different senses
in different branches of computer science. In databases, atomicitity
is one of the ACID properties (along with consistency, isolation, and
durability), and database people would consider that the last property
I mentioned, that logically everything else happens either before or
after the atomic operation, is isolation, not atomicity. But someone
talking about, e.g., an atomic increment operation would have that as
their primary meaning.
--
Evan Kirshenbaum +------------------------------------
HP Laboratories |A specification which calls for
1501 Page Mill Road, 1U, MS 1141 |network-wide use of encryption, but
Palo Alto, CA 94304 |invokes the Tooth Fairy to handle
|key distribution, is a useless
kirsh...@hpl.hp.com |farce.
(650)857-7572 | Henry Spencer
Skitt
> Mark Brader wrote:
>>>>> Just as "performance" or "speed" is the noun form of "fast" (or
>>>>> "quickly"), what is the noun form of "atomic" in the sense of
>>>>> indivisible ?
>>>>>
>>>>> "Indivisibility" does not have the right ring to it.
>>>>>
>>>>> Any ideas ?
>>>>
>>>> Atomicity.
>>>
>>> Opinions are split on that one.
>>
>> Atomicity.
>
> Sal's joke bombed.
Hey! It was my joke.
--
Skitt (in Hayward, California)
http://www.geocities.com/opus731/
Paul Wolff
<dado...@spamcop.net> writes
>richardchaven filted:
>>
>>Just as "performance" or "speed" is the noun form of "fast" (or
>>"quickly"), what is the noun form of "atomic" in the sense of
>>indivisible ?
>>
>>"Indivisibility" does not have the right ring to it.
>
>Nonetheless, it is as near the right word as any you're going to find...note
>that the word "atom" comes from the Greek roots "a-" ("not") and "tomos" ("to
>cut"), so an atom is simply that which can't be cut into smaller pieces....r
>
--
Paul
In bocca al Lupo!
Jeffrey Turner
> Jeffrey Turner wrote:
>
>> Mark Brader wrote:
>
>
>>>>>> Just as "performance" or "speed" is the noun form of "fast" (or
>>>>>> "quickly"), what is the noun form of "atomic" in the sense of
>>>>>> indivisible ?
>>>>>>
>>>>>> "Indivisibility" does not have the right ring to it.
>>>>>>
>>>>>> Any ideas ?
>>>>>
>>>>>
>>>>> Atomicity.
>>>>
>>>>
>>>> Opinions are split on that one.
>>>
>>>
>>> Atomicity.
>>
>>
>> Sal's joke bombed.
>
>
> Hey! It was my joke.
Sorry. I don't know why Mark deleted the attributions.
vorot...@yahoo.com
Use it in a sentence.
vorot...@yahoo.com
Use it in a sentence.
Peter Moylan
> BST wrote:
>> Be that as it may, the answer to richardchaven's question is "atomicity".
>
> Use it in a sentence.
And so here we'll stay
Till the very day
We find out what atomicity means.
[With apologies to Kermit the Frog]
--
Peter Moylan http://www.pmoylan.org
Please note the changed e-mail and web addresses. The domain
eepjm.newcastle.edu.au no longer exists, and I can no longer
receive mail at my newcastle.edu.au addresses. The optusnet
address could disappear at any time.
Mark Brader
>>>>> "quickly"), what is the noun form of "atomic" in the sense of
>>>>> indivisible ?
>> ... the answer to richardchaven's question is "atomicity".
> Use it in a sentence.
"The atomicity of ln(1) makes it a safe way to implement a semaphore."
--
Mark Brader "The design of the lowercase e in text faces
Toronto produces strong feelings (or should do so)."
m...@vex.net -- Walter Tracy
R H Draney
>
>BST wrote:
>>
>> Be that as it may, the answer to richardchaven's question is "atomicity".
>
>Use it in a sentence.
He just did....r
Roland Hutchinson
> vorot...@yahoo.com filted:
>>
>>BST wrote:
>>>
>>> Be that as it may, the answer to richardchaven's question is
>>> "atomicity".
>>
>>Use it in a sentence.
>
> He just did....r
Not so. He mentioned it. He did not use it.
He did, however, use "it".
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to my.spamtrap [at] verizon.net is heavily filtered to
remove spam. If your message looks like spam I may not see it.
Roland Hutchinson
>>>>>> Just as "performance" or "speed" is the noun form of "fast" (or
>>>>>> "quickly"), what is the noun form of "atomic" in the sense of
>>>>>> indivisible ?
>
>>> ... the answer to richardchaven's question is "atomicity".
>
>> Use it in a sentence.
>
> "The atomicity of ln(1) makes it a safe way to implement a semaphore."
Lovely example.
Explains why my home directory very slowly fills up with lock files left
behind by application crashes, too.
Evan Kirshenbaum
The atomicity of the increment operator ensures that the resulting
count will be correct in the face of simultaneous updates in
different threads, which might not be the case if normal addition
and assignment were used.
For those who are curious, a non-atomic increment would have three
steps:
1. Read the current value
2. Compute the new value by adding one
3. Store the new value
If two separate entities try to do this at roughly the same time, it
is quite possible to have the following scenario:
Counter holds 5
A.1 Entity A learns that the value is 5
A.2 Entity A computes the new value to be 6
B.1 Entity B learns that the value is 5
B.2 Entity B computes the new value to be 6
B.3 Entity B stores 6 as the new value
A.3 Entity A stores 6 as the new value
We started at 5, incremented twice, and came up with a value of 6. If
the increment is atomic, this can't happen: either A's increment
happens completely before B's starts or B's happens completely before
A's starts, so we have to wind up with 7.
--
Evan Kirshenbaum +------------------------------------
HP Laboratories |First Law of Anthropology:
1501 Page Mill Road, 1U, MS 1141 | If they're doing something you
Palo Alto, CA 94304 | don't understand, it's either an
| isolated lunatic, a religious
kirsh...@hpl.hp.com | ritual, or art.
(650)857-7572
Mark Brader
> For those who are curious, a non-atomic increment would have three
> steps:
>
> 1. Read the current value
> 2. Compute the new value by adding one
> 3. Store the new value
>
> If two separate entities try to do this at roughly the same time, it
> is quite possible to have the following scenario:
>
> Counter holds 5
> A.1 Entity A learns that the value is 5
> A.2 Entity A computes the new value to be 6
> B.1 Entity B learns that the value is 5
> B.2 Entity B computes the new value to be 6
> B.3 Entity B stores 6 as the new value
> A.3 Entity A stores 6 as the new value
>
> We started at 5, incremented twice, and came up with a value of 6. If
It's even worse if we imagine a "store" operation that itself is
non-atomic, writing to the different bits individually. Then when
the first entity overwrites the stored value 5 with 6, it will
intermediately take on the value 4 or 7, depending on which bit
changes first. If the other entity chooses that moment to read it,
the final result could be 5 or 8 -- or still other values if it can
complete the computation and start storing bits before the first one
finishes storing its result.
The standard for the programming language C addresses such issues using
the concept of "sequence points", and in a situation where there are no
sequence points to prevent potentially overlapping accesses such as Evan
and I describe, the standard allows the program to do *anything*.[1]
(In particular, none of the common expressions to increment a variable
produces, by itself, a sequence point.) If someone wants to implement
standard C on a machine where storing a value is a non-atomic operation,
the standard will not prevent it. Caveat programmor.
[1] As John F. Woods put it in a 1992 comp.std.c posting: "demons may
fly out of your nose." The joke was soon summarized by the phrase
"nasal demons" and is still repeated in the C newsgroups to this day.
--
Mark Brader At any rate, C++ != C. Actually, the value of
Toronto the expression "C++ != C" is [undefined].
m...@vex.net -- Peter da Silva
My text in this article is in the public domain.
Evan Kirshenbaum
> The standard for the programming language C addresses such issues
> using the concept of "sequence points", and in a situation where
> there are no sequence points to prevent potentially overlapping
> accesses such as Evan and I describe, the standard allows the
> program to do *anything*.[1]
Actually, sequence points are there to constrain what the compiler is
allowed to do within a single thread (which is all that C really knows
about). If there's more than one thread hammering on a particular
variable, all bets are off and you have to use higher-level
synchronization mechanisms or low-level atomic operations.
Or trust to luck. My first patent was, in part, for a mechanism for
implementing a counter when (1) you didn't have atomic operations to
take advantage of, (2) you couldn't afford the overhead of a mutex,
(3) you didn't really care about the value of the counter, but you
needed to know when (and as soon as) it got back down to zero, and (4)
once it hit zero, it would never move again. The solution we came up
with was probabilistic, but the probability of failure (requiring
multiple context switches between the same two threads very close
together) was tolerable.
--
Evan Kirshenbaum +------------------------------------
HP Laboratories |Those who study history are doomed
1501 Page Mill Road, 1U, MS 1141 |to watch others repeat it.
Palo Alto, CA 94304
kirsh...@hpl.hp.com
(650)857-7572
Mark Brader
> > The standard for the programming language C addresses such issues
> > using the concept of "sequence points", and in a situation where
> > there are no sequence points to prevent potentially overlapping
> > accesses such as Evan and I describe, the standard allows the
> > program to do *anything*.
> Actually, sequence points are there to constrain what the compiler is
> allowed to do within a single thread (which is all that C really knows
> about). If there's more than one thread hammering on a particular
> variable, all bets are off and you have to use higher-level
> synchronization mechanisms or low-level atomic operations.
You say "actually" as if this was a correction. Multiple threads or
processes are, as you say, outside the scope of the language.
> Or trust to luck. My first patent was, in part, for a mechanism for
> implementing a counter when (1) you didn't have atomic operations to
> take advantage of, (2) you couldn't afford the overhead of a mutex...
Not bad!
--
Mark Brader | "I have on occasion manufactured technical terms that
Toronto | have made it into common use in the literature.
m...@vex.net | But not many, and I'm licensed." --John Lawler
Evan Kirshenbaum
> Mark Brader:
>> > The standard for the programming language C addresses such issues
>> > using the concept of "sequence points", and in a situation where
>> > there are no sequence points to prevent potentially overlapping
>> > accesses such as Evan and I describe, the standard allows the
>> > program to do *anything*.
>
> Evan Kirshenbaum:
>> Actually, sequence points are there to constrain what the compiler
>> is allowed to do within a single thread (which is all that C really
>> knows about). If there's more than one thread hammering on a
>> particular variable, all bets are off and you have to use
>> higher-level synchronization mechanisms or low-level atomic
>> operations.
>
> You say "actually" as if this was a correction. Multiple threads or
> processes are, as you say, outside the scope of the language.
That's why I said "actually". I don't consider thread contention to
be the type of issue that sequence points were introduced to address,
which seemed to be what you were implying.
>> Or trust to luck. My first patent was, in part, for a mechanism for
>> implementing a counter when (1) you didn't have atomic operations to
>> take advantage of, (2) you couldn't afford the overhead of a mutex...
>
> Not bad!
Thanks.
--
Evan Kirshenbaum +------------------------------------
HP Laboratories |On a scale of one to ten...
1501 Page Mill Road, 1U, MS 1141 |it sucked.
Mark Brader
>>>> The standard for the programming language C addresses such issues
>>> Actually, sequence points are there to constrain what the compiler
>>> is allowed to do within a single thread (which is all that C really
>>> knows about). If there's more than one thread hammering on a
>>> particular variable, all bets are off ...
>> You say "actually" as if this was a correction. Multiple threads or
>> processes are, as you say, outside the scope of the language.
> That's why I said "actually". I don't consider thread contention to
> be the type of issue that sequence points were introduced to address,
> which seemed to be what you were implying.
The issue that sequence points were introduced to address was the conflict
between programmers desiring a language where the order of operations was
fully specified and implementers desiring one where it was maximally
flexible. The resolution of the issue is that the user can assume things
are fully specified as of each sequence point, but the implementer can
do things in any order between sequence points, and the user must not
write code that would be affected by the order. In this, "simultaneously"
is a possible order, irrespective of whether there are threads in the
context that Evan refers to, and this is precisely why nasal demons are
a possibility.
--
Mark Brader, Toronto | "When you're up to your ass in alligators, maybe
m...@vex.net | you're in the wrong swamp." -- Bill Stewart